Yeah, the branch name is very fitting 🙃 This approach is going to read and parse the file for each stored resources every time we need to figure out its icon. Even if this information doesn't change, we would still parse the file, at least partially, to fetch the type information.

This definitely needs some cache, and that's what reduz wanted as well, I believe. To utilize the editor file system somehow, and only update the information when the underlying data, like the type or the script, changes. This way we would only have to run this expensive operation on change rather than on fetch.

I believe that the PR this one is supposed to supersede was going this route. After a lot of discussion they've hooked into the preview generator process, since it already needs to run for a changed resource. Maybe it's not the best place to hook into, but at least it creates an accessible cache for us to use on the file tree refreshes.

So in the end, I would not merge this in its current state and look for a more optimal approach using some sort of cache.

I think the icons can be cached locally, we already do this with scene tree (see #60789). I'll look into that, I thought get_class_icon() already uses it...

Ok rebased and updated. I used EditorFileSystem's cache to get resource icon, but it has caveats:

• it assumes the first dependency in the file is its Script
• it checks whether that dependency is actually a Script (not sure how fast is that)

I added a temporary HashMap that stores cache for each script path, so it shouldn't be too slow, but testing appreciated. If it's slow, it will affect file tree updates.

EDIT:
Tested in a big project and it doesn't seem to be particularly slow. Rescan takes the most time as normally.

Thanks!